home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15935 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 13:54:35 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kbuebINNrho@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <dewar.828987544@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  12.  >With respect to read (Linux unusual behavior), Lawrence said
  13.  >
  14.  >"Both approaches meet the relevant standards and are correct. Only broken
  15.  >code has portability problems, but that's nothing new."
  16.  >
  17.  >Can you quote the relevant standard. No description of read I ever saw
  18.  >was detailed or precise enough to say what the requirements on the caller
  19.  >are.
  20.  >
  21.  >Lots of code is portable and broken, lots of code is (deliberately)
  22.  >non-portable and definitely not broken. Lots of code is carefully
  23.  >written to be portable, but runs into bugs in supposedly conforming
  24.  >implementations. Lots of code uses features that are useful, but for
  25.  >which no standard exists, and hence may run into portability problems.
  26.  
  27. In this case, it is safe to assume that the caller of read() had better not lie
  28. to the system call. The buffer size is the de-facto ``advertized'' buffer size,
  29. and all of the buffer up to the given size should be backed by valid storage.
  30.  
  31. It would not even occur to me to advertize a buffer of size N, but pass a
  32. pointer to a buffer of size M < N to the POSIX read() function, or in any way
  33. rely on the nature of the checking done by the kernel.
  34.  
  35. This is so deeply entrenched in the realm of common sense that it isn't even
  36. worth mentioning in a standard document! Nevertheless, I have access to the
  37. POSIX.1 standard and will look into this.
  38. -- 
  39.  
  40.